One example of a known communication system of the type stated above is a CAN (controller area network) communication system. What is involved here is an asynchronous, serial bus system, developed in 1983 by Bosch, for the networking of control units in automobiles, and introduced in 1986 (cf. SAE Paper 860391, International Congress and Exposition, Detroit, Mich., Feb. 24-28, 1986) together with Intel, in order to reduce the length of wiring harnesses in motor vehicles, and thereby to save space and weight. The use of the CAN bus is not limited to the automotive field, however. The CAN bus has meanwhile found its way into building management systems and into machine tools. In a CAN bus, data transmission takes place in so-called data frames which, besides the user data that are to be transmitted (the actual messages) also have configurational data at the beginning (the header part) and test data at the end (the CRC part) of the frame. Other examples of a known communication system of the above-mentioned type are a FlexRay bus, a MOST (media oriented systems transport) bus or any field bus, such as a LIN (local interconnect network) bus.
In CAN and other protocols, messages are transmitted between a first and a second subscriber node by an application program of the first subscriber node copying the message to be sent into a message memory, from where, upon a send command of the application program, it is retrieved by a communication controller and transmitted via the data bus. It is frequently necessary, in this context, to inform the application program on the result of transmission jobs and the possible cancellation of transmission jobs. This is the case, for example, if, during the processing of a transmission job, an additional, more urgent transmission job comes in. In such a case, the pending transmission job is canceled, but a sending process that has already been started (start of frame (SOF) bit already sent) is not broken off, but is continued until either the arbitration is lost, an error occurs or the message has been successfully sent. In the case of CAN and other protocols, data are transmitted serially, and under certain circumstances it can take a long time until the end of the data frame is reached. During this time, the computing unit (CPU; central processing unit) of the subscriber node is practically blocked, since it has to await the end of the data frame. This may additionally lead to an unacceptable delay in the processing of the further, more urgent transmission job.
Only after the end of the data frame of the first transmission job has been reached, is the CPU able to attend to the urgent transmission job. For this, the application program of the subscriber node copies the message to be sent of the urgent transmission job in a message memory, from where it is retrieved by a communication controller upon a sending command of the application program, and is transmitted via the data bus. After taking care of the urgent transmission job, the application program continues again with the interrupted transmission. For this purpose, it is required that information on the status of the transmission job processed before the urgent request be available to the application program. The application program should have the possibility of informing itself on the result of transmission jobs and the possible cancellation of transmission jobs.
That is why, in the case of the known subscriber nodes, the message memories, whose content is to be sent, are connected using status bits. Frequently, only the success of a transmission job is able to be indicated in the status bits. Some results, especially in the case of a cancellation of a transmission job (Tx cancellation), are not able to be shown with the aid of the status bits.